昨天說到，AI 已經可以回答絕大多數 QA 的知識型問題。

今天來說一個王小明的故事：如果太相信 AI，就可能把一個真的 Bug 放上線。

故事如下

▲ 那天早上，自動化測試的排程跑完，有一支 E2E 測試失敗了。
▲ 那支測試在跑一個結帳流程，最後一步驗證訂單狀態的時候錯誤了。

這種事其實每週都會發生幾次。做自動化測試的人都知道，測試失敗不等於產品有 Bug，可能是：

• 測試環境剛好在重啟
• 前置資料沒準備好
• 網路慢了一下

通常是單純的 Flaky（不穩定的測試，同樣的程式碼有時過有時不過）

所以王小明做了現在很自然的一件事：把失敗報告丟給 AI。

AI 給的答案，非常合理

▲ 他把 程式碼、API log、失敗截圖都餵進去，AI 大概 1 分鐘後就回：

▲ 這是一個典型的 Flaky Test。從 trace 可以看到元素在 5.2 秒才渲染完成，而等待條件設定為 5 秒，屬於邊界時間問題。
▲ 建議：將等待時間調整為 10 秒，或改用明確的元素等待條件。此次失敗與產品邏輯無關。

老實說，這個回答分析得滿漂亮。因為：

• 它有引用具體數據（5.2 秒 vs 5 秒）
• 它有明確的因果推論
• 它有給出可執行的修法
• 它甚至還下了結論：與產品邏輯無關

他當下的反應是：「喔，那就是 Flaky，改一下等待時間就好。」

於是就把等待時間調長，重跑，過了。

看起來一切正常，可以收工了。

那天他確實差一點就這樣關掉視窗。

但有經驗的小明總覺得有個地方怪怪的

▲ 純粹是習慣，關掉之前，王小明順手翻了一下這支測試的歷史紀錄。

▲ 它已經跑了大半年，一直都很穩。但最近 10 天內失敗了 4 次，而且卡的都是同一個步驟。

這件事讓王小明停下來了。

因為如果是測試本身寫得不夠穩（也就是真正的 Flaky），它不會挑時間開始不穩定。

一支穩定跑了大半年的測試，突然在某個時間點之後開始間歇性失敗，這通常只代表一件事：

不是測試變了，是它測的東西變了。

於是王小明回頭做更深入的排查 。

真正的原因

▲ 那個訂單狀態在後端有兩段流程會寫到同一份資料，但沒有做好順序上的鎖定（lock）。

▲ 也就是說，誰先寫完是不保證的。

▲ 而這個缺陷其實一直都在，只是前陣子那一版新增了第二段寫入流程之後，兩邊才開始搶。

這也解釋了為什麼這支測試安穩跑了大半年，卻是最近十天才開始出事。

實際跑起來，會有三種結果：

• 大部分時候：順序剛好是對的，狀態正常回傳，測試就過了
• 有時候：後段流程只是慢了一點，資料最後還是對的，等久一點就會等到
• 少數時候：順序整個顛倒，寫進去的狀態根本就是錯的

▲ 而最後那種情況，前端拿到的 API 回傳一樣是 Status code 200，加上前端剛好也沒做欄位內容的驗證，所以畫面不會報錯，就只是停在那裡什麼都不做。

這是典型的 race condition（競態條件，簡單講就是「兩件事同時搶著做，誰先誰後不固定」）。

而 race condition 的表徵，跟 Flaky Test 長得一模一樣：有時候過，有時候不過。

這也是為什麼 AI 那個判斷看起來這麼合理。

但兩者要修的地方完全不同：

回頭看王小明把等待時間從 5 秒改成 10 秒這件事。

它確實有效——但只對「慢」的那種情況有效。

資料只是慢的那幾次，等久一點就等到了，測試就有機率 PASS。

所以加長等待時間做的事情，不是修好它，是讓它更不容易被抓到。

而這種 Bug 不會在上線當天爆，會在某個流量比較大的下午突然冒出來。

AI 到底錯在哪？

王小明的故事就講到這裡。接下來換我自己的觀察。

這個案例最有意思的地方在於，就以 AI 的當下推論其實沒錯。因為：

• 元素確實 5.2 秒才出現 ✅
• 等待條件確實設 5 秒 ✅
• 加長等待時間確實會讓測試通過 ✅

它的每一個觀察都正確，最後的結論卻是錯的。

錯的是中間跳掉的那一步。

畢竟間歇性失敗，可能是測試不穩，也可能是產品不穩。

AI 直接走了前者，因為在它拿到的資料中，那條路完全說得通。

而 AI 之所以沒看到第二條，是因為它只能看到你餵給它的東西。

王小明給的是一次失敗的程式碼、log、截圖，在那個範圍裡，「Flaky」其實是很好的答案。

但它看不到：

• 這支測試過去大半年都是穩的，是最近才開始失敗
• 這個狀態在後端有兩段流程會寫到同一份資料
• 這個產品這一版到底動過哪些東西

AI 給的是「在你提供的資訊範圍內，最合理的解釋」。

而這句話裡面藏了一個很危險的前提：你提供的資訊範圍夠不夠？

這個判斷，AI 做不了，只有你能做。

為什麼這種錯誤特別危險

如果 AI 給的是一個很扯的答案，其實不危險，因為你一眼就看出來了。

真正危險的是這種：

• 邏輯完整
• 有數據支撐
• 有可執行的建議
• 而且照著做，問題「看起來」解決了

它甚至幫你製造了一個成功的假象：測試變 PASS 了。

把這種情況我都稱為「安靜的錯誤」。

它不會讓你發現自己錯了，它會讓你覺得自己做完了。

而 QA 這個職位，最不能接受同時也最應該害怕的就是這個！

我們 QA 的工作不是讓測試變綠，是知道產品到底有沒有問題。

所以我時常問三個問題

不是什麼方法論，就是三個很土炮的自我提醒。

第一：AI 看到的資訊，涵蓋範圍夠嗎？

它只看到這一次的失敗，還是看得到歷史？它知道這版改過什麼嗎？如果答案是「不知道」，那它的結論就只是「在很窄的視野下最合理的猜測」。

第二：這個結論如果是錯的，代價是什麼？

「這段程式碼可以簡化」如果錯了，代價是我多花十分鐘。
「Flaky，重跑就好」如果錯了，代價是一個 Bug 上線。

畢竟代價差這麼多的時候，成本與風險就會差很多。

第三：有沒有一個一分鐘就能做的反向驗證？

以上述的例子來說，就是「看一下歷史失敗紀錄」跟「手動跑一次」。

大部分時候，推翻一個錯誤結論需要的成本，遠比你以為的低很多。畢竟 真正貴的是完全不驗證。

總結

透過上述的例子，其實就能知道，問題其實不是出在 AI 身上。

AI 表現其實很好，它在有限的資訊下給出了最合理的推論，這已經超過很多人了。

更何況如果還是要貴的模型，那成效可能會更好XDDD

AI 問題出在把「合理的推論」直接當成了「結論」。

這兩者中間，就需要有一個人站在那裡，問一句「等等，這說得通嗎」。

AI 讓技術門檻大幅降低，這是好事，我完全支持。

不會寫自動化的人現在也能寫出能跑的測試，放眼四年之前是不可能的。

但門檻降低會帶來一個副作用：

當取得答案變得太容易，「驗證答案」這件事就會被跳過。

而 QA 的價值，從來就不是在於我們知道多少答案或者對產品有多熟悉。

而應該是 是我們要主動的百次！千次！的確認那個答案對不對，有沒有問題、合不合理。

明天換個角度。

前面兩天講的，都還停留在「一個人」的層級。
但當團隊從 5 個人變成 30 人的時候，這件事會變成一個完全不同的問題

不是「我有沒有判斷力」，而是「這個判斷力，怎麼讓所有個人都有」。